-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to babel preset env + async/await/generator support #1668
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General gist looks good, not sure about enabling mangle
@@ -29,7 +29,7 @@ export default function() { | |||
screw_ie8: true, | |||
warnings: false, | |||
}, | |||
mangle: false, | |||
mangle: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would also affect code written by consumers of storybook, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, should be safe right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is okay because its the prod config that compiles a static bundle. Presumably, users wouldn't be debugging from a static file served on an http host somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, and they could add sourcemaps if required using custom webpack config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not about debugging, it's about the prod deployment of as storybook being broken. I don't think enabling mangle
is safe and it would mean that in Dev mode everything might be fine but the storybook deploy could be broken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I think we need to be conservative in these things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have an actual non-theoretical example @joscha ?
This saves A LOT of bytes in the production bundle, which is one of the issues I need to resolve to get automatic example deployment working.
I'm gonna go ahead with this unless someone can provide me a non-theoretical reason not to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My example is not theoretical?! We have these problems a the time with Closure Compiler before we write externs for it, that prevent Closure from thinking it can just mangle names. The last one we had was the defaultProps
of React components. Another one would be CSS modules - renaming props on there means that object access won't work any more, e.g. where before you could do styles[variable]
it would break after. Also anything with eval
assuming state being accessible by a named property will break. It saves a lot of bytes, but it's not a safe transformation, that's why it is an option and not on by default. Not making the assumption that just because it will work inside storybook (which we not even know for sure, because the tests don't run against the prod build) for a lot of people using storybook will save these people and the maintainers a lot of time and debugging pain in the future at the expense of a few bytes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree with @joscha on this. let's be conservative here and reduce our bundle size by eliminating bogus dependencies. we can also provide a recipe for how to opt-in on this for people who want it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reverted
], | ||
plugins: [ | ||
// function x(a, b, c,) { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these comments are kinda helpful to figuring out what these transforms do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mah, I find the package names pretty self-explanatory. I wonder if I can just switch this to babel-preset-stage-n?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that might make everyone's lives easier.
I actually see these things as an custom babel config templates for users as well. we really don't have any documentation on what sort of plugins users would need to correctly compile storybook with their own configs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's because we're not maintaining/documenting babel..
It's just a .babelrc
. would you expect us to document/instruct people how to config that?
require.resolve('babel-preset-env'), | ||
{ | ||
targets: { | ||
browsers: ['last 2 versions', 'safari >= 7'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we're targeting every browser > 1%
in the style prefixer:
https://github.com/storybooks/storybook/blob/master/app/react/src/server/config/defaults/webpack.config.js#L30
I think whichever one we decide on, we should keep the two uniform.
my opinion is that storybook should be on as wide of a platform as we can effortlessly support so users can view what components look like in say IE10 or FF ESR releases. last 2 versions seem really restrictive to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this remark, what do you suggest we use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like what the other config is targeting. maybe we can merge the safari >= 7
in there as well. seems to basically support most browsers in the last 5 years
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so users can view what components look like in say IE10
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Hypnosphi we can't make these kind of decisions for developers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every tool for or -working in- browsers has made some consideration on how backwards compatible they are.
We can provide what we think is a sane default. We already provide developers with ways to change this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote we target:
- IE 11
- FF ESR
- last 4 versions of Edge, Safari, Chrome, Firefox
require.resolve('babel-preset-stage-0'), | ||
require.resolve('babel-preset-react'), | ||
], | ||
plugins: [ | ||
require.resolve('babel-plugin-transform-regenerator'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty opposed to this plugin because we don't have it in our code base and I would hope we wouldn't need to polyfill it in the future because of the compiled bundle size and performance on browsers that don't natively support generators.
see generators section:
http://incaseofstairs.com/2015/06/es6-feature-performance/
it should probably be a custom babel config if users are looking for this plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You think we should prevent people from using async/await/generators if not supported by their browser?
On the other hand we have people opening issues expecting support for it.
And in this same PR I'm asked to support browsers from ±5 years ago.
I feel like I'm, in a no-win situation here 😃
I get where you're coming from. enabling this means enabling it for all browsers even the ones that DO support it right?
I agree that's bed considering how much lower the performance is of the transpiled code vs native implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like people are using async in their code and are expecting this. i'd vote that we support out of the box it even if it leads to a little bloat. we can also provide a recipe for how to opt out with custom .babelrc
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My gripe with polyfills is that that the older and less powerful the system is, the more performance hit you get. I'm okay with single digit multiples to a certain extent, but when generators polyfill to be 100x-700x slower, an operation that takes 10ms to complete will now take 1s-7s on the thread in FF, IE, and old mobile browsers? you pretty much get a frozen window at that point :(
It does look like a popular request so I'm gonna give in and support this one. I really hope people who are using these polyfills know the performance implication of what they're doing too.
41fd3a5
to
a9b55dc
Compare
Codecov Report
@@ Coverage Diff @@
## master #1668 +/- ##
=========================================
Coverage ? 21.13%
=========================================
Files ? 247
Lines ? 5582
Branches ? 668
=========================================
Hits ? 1180
Misses ? 3910
Partials ? 492
Continue to review full report at Codecov.
|
So do we use both babel-minify and UglifyJS at the same time? Why? |
babel-minify operates per file, and removes dead code webpack babili plugin would be a replacement for uglify plugin, but i want to wait till that's final. |
I'd be interested in running prepack on the bundle too. |
So it's only for dead code in terms of file, unused exports can't be eliminated that way because it runs before webpack, right? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my comment about mangle: true
Thanks everyone for reviewing. I hope you also feel this PR is an improvement. maybe not quite perfect. |
Fixes: #1667
Possible fix for: #1665, #489
Possible fix for: #1570
What I did
I changed all usages of babel-preset-es20xx to babel-preset-env
I also added babel-minify
And I enabled webpack tree-shaking
How to test
Run the examples
Build the static versions of the examples